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NORT-0093-US 
(13555RRUS02U) 

PROTOCOL HEADER CONSTRUCTION AND/OR 
REMOVAL FOR MESSAGES EST WIRELESS COMMUNICATIONS 

CROSS-REFERENCE TO RELATED APPLICATION 
This claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Application 
No. 60/238,410, filed October 6, 2000. 



5 TECHNICAL FIELD 

This invention is generally related to reconstruction and/or removal of protocol 
headers in messages in wireless communications. 



BACKGROUND 

1 0 Packet data networks are widely used to link various types of network elements, 

such as personal computers, servers, network telephones, Internet appUances, and so 
forth. Examples of data networks include private networks (such as local area networks 
or wide area networks) and public networks (such as the Internet). Common forms of 
communications between network elements across packet data networks include 

1 5 electronic mail, file transfer, web browsing, and other exchanges of data. More recently, 
with the increased capacity and rehability of packet data networks, audio 
communications (such as voice communications), video communications (such as video 
conferencing), and other forms of real-time interactive or streaming communications are 
becoming more common over packet data networks. 

20 With advancements in wireless communications networks, efficient packet- 

switched communications over wireless networks have also become possible. 
Traditionally, wireless communications networks have been implemented as circuit- 
switched networks. In a circuit-switched network, a channel portion (such as a time slot) 
between two endpoints (e.g., two mobile stations) is occupied for the duration of the 

25 connection between the endpoints. 

Several packet-switched wireless technologies have been proposed to provide 
more efficient connections between a mobile station and a packet data network, such as 



an Internet Protocol (IP) network. One such technology is the General Packet Radio 
Service (GPRS) technology, which provides for packet services in GSM (Global System 
for Mobile) networks, UMTS (Universal Mobile Telecommunications System) networks, 
or GERAN (GSM/EDGE radio access network) network. EDGE, which stands for 
Enhanced Data Rate for Global Evolution, is compatible with GSM and TIA/EIA-136 
TDMA (time-division multiple access) wireless communications technologies. UMTS is 
based on the wideband code-division multiple access (W-CDMA) wireless 
conomunications technology. 

Packet services that are provided by such packet-switched wireless technologies 
include traditional packet services such as web browsing, electronic mail, file transfer, 
and so forth. Additionally, real-time and interactive packet services, such as telephony 
services (e.g., voice-over-IP services) are also provided. In voice-over-IP 
communications, voice traffic is carried in packets (referred to as "packet-switched voice 
traffic"). 

One of the issues associated with carrying packet-switched voice traffic over a 
wireless link or air interface between the mobile station and radio network controller is 
that new channel coding and interleaving schemes may have to be developed. Typically, 
traffic channels that carry circuit-switched traffic have predetermined and standardized 
coding and interleaving schemes. As example coding and interleaving scheme is 
described in the GSM 05.03 Specification (Version 8.50 Release 1999). Developing and 
adopting new standards for packet-switched voice traffic (and other bearer traffic) can be 
a relatively long process requiring several rounds of negotiation between different parties. 
Also, equipment that has been manufactured to support old standards may not be able to 
support new, modified standards. 

Packet-switched traffic (e.g., voice) is accompanied by overhead information in 
the form of protocol headers, e.g., Real-Time Protocol (RTP) headers. User Datagram 
Protocol (UDP) headers, and Internet Protocol (IP) headers. Such headers are rather 
large and can take up substantial amounts of bandwidth, especially since the protocol 
headers are communicated in each and every packet. As a result, communication of such 
headers over the air interface between a mobile station and radio equipment causes a 
reduction of the spectral efficiency of the air interface. 
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SUMMARY 

In general, according to one embodiment, a method of communicating data over a 
wireless link between a mobile station and a wireless access system comprises 
communicating, over the wireless link, control signaling for setting up a packet-switched 
5 communications session between the mobile station and an endpoint. Packets containing 
real-time data are communicated over the wireless link, with at least one protocol header 
associated with the packet-switched communications being removed from each packet 
before communicating the packet over the wireless link. 

Other or alternative features will become apparent from the following description, 
10 from the drawings and from the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram of an example of a wireless communications network. 
Fig. 2 illustrates an Intemet Protocol (IP) packet for carrying real-time bearer 

15 traffic. 

Fig. 3 is a message flow diagram of a process of estabUshing communications 
between a mobile station and another endpoint in the wireless communications network 
of Fig. 1, in accordance with an embodiment. 

Figs. 4 and 5 are flow diagrams of processes for receiving and transmitting bearer 

20 data. 

Fig. 6 is a block diagram of components in a mobile station and a radio network 
controller, in accordance with an example, 

DETAILED DESCRIPTION 
25 In the following description, numerous details are set forth to provide an 

understanding of the present invention. However, it will be understood by those skilled 
in the art that the present invention may be practiced without these details and that 
numerous variations or modifications from the described embodiments may be possible. 
Referring to Fig. 1, a conmiunications network 10 includes a wireless core 
30 network 1 1 that enables communications with mobile stations (e.g., 16, 18, 20, and 22). 
The wireless core network 1 1 includes radio access network (RAN) equipment 12 and 14 
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for communicating with the mobile stations 16, 18, 20 and 22 over wireless hnks. A 
wireless link is also referred to as an air interface. The radio access network equipment 
12 includes a GSM/EDGE (Global System for Mobile/Enhanced Data Rate for Global 
Evolution) radio access network (GERAN) system. GERAN provides for enhanced data 

5 rates for best-effort services (e.g., web browsing, electronic mail, and so forth) and real- 
time traffic (e.g., voice-over-Internet Protocol or voice-over-IP). A version of IP, 
referred to as IPv4, is described in Request for Comments (RFC) 791 , entitled "hitemet 
Protocol," dated September 1981. Another version of IP is IPv6, which is described in 
RFC 2460, "Internet Protocol, Version 6 (IPv6) Specification," dated December 1998. 

1 0 The radio access network equipment 14 includes a UMTS (Universal Mobile 

Telecommunication System) terrestrial radio access network (UTRAN) system. The 
UTRAN system 14 is based on the wideband code-division multiple access (W-CDMA) 
technology. 

The GERAN system 12 includes a GERAN base station transceiver (or radio) and 
1 5 a GERAN radio network controller (RNC), and the UTRAN system 14 includes a 

UTRAN base station transceiver and a UTRAN radio network controller (RNC). More 
generally, a "wireless access system" refers to any system (such as the GERAN or 
UTRAN base station transceiver and RNC), implemented as one or plural modules, that 
is capable of communicating with mobile stations over defined channels on wireless 
20 links. 

The GERAN radio network controller is coupled to a serving GPRS (General 
Packet Radio Service) support node (SGSN) 24 over a Gb Unk or an lu link (specifically 
an lu-ps link for packet-switched data). Signaling and user data can be communicated 
between the GERAN radio network controller and SGSN 24 over each of the Gb and lu 

25 links. The UTRAN radio network controller is coupled to the SGSN 24 over an lu link 
(specifically an lu-ps Unk for packet-switched data). The SGSN 24 (along with the 
GGSN 26 and the RNC portions of the GERAN system 12 and UTRAN system 14) 
controls the estabUshment, processing, and termination of packet-switched 
communications sessions between mobile stations 16, 18, 20 and 22 and another 

30 endpoint. 
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The SGSN 24 is in turn coupled to a gateway GPRS support node (GGSN) 26 
over a Gn interface. The GGSN 26 acts as a gateway between the wireless core network 
11 and a packet network 28, such as the hitemet or other type of packet network or even 
another wireless core network. The GGSN 26 is coupled to an edge or border gateway 
5 router (not shown) ui the packet data network 28 over a Gi interface. The packet network 
28 is coupled to various endpoints, such as a PC telephone 30 and a user station 32 (e.g., 
a computer system). 

The GGSN 26 is also coupled to a media gateway (MGW) 34 over a Gi interface. 
The media gateway 34 acts as a gateway for communications of bearer traffic between 

10 (1) the wireless core network 11 and a circuit-switched network such as a public switched 
telephone network (PSTN) 36 and (2) the wireless core network 1 1 and the Internet 28 
(in the event that transcoding is required for wireless Internet technology to 
wireless/landline Internet telephone calls). The PSTN 36 is coupled to various terminals 
38, such as telephones, and the Litemet 28 is coupled to various terminals 30, 32, such as 

15 PC telephones. 

The wireless core network 11 also includes a call state control function (CSCF) 
module 40 that provides call control for a packet-switched communications session. In 
some embodiments, the CSCF module 40 is a (Session Initiation Protocol) SIP proxy or 
server that receives call requests on behalf of other entities, resolves logical addresses or 

20 identifiers in the call requests, and forwards the call requests to intended destinations. 

SIP defines a call establishment protocol that can be used to initiate call sessions as well 
as to invite members to a session that may have been advertised by some other 
mechanism, such as electronic mail, news groups, web pages, and other mechanisms. A 
version of SIP is described in RFC 2543, entitied "SIP: Session Initiation Protocol," 

25 dated August 1999. In other embodiments, other types of call control protocols or 
standards can be used, such as the H.323 standard. 

Another module in the wireless core network 1 1 is a media gateway control 
fimction (MGCF) module 42 that provides (1) signaling conversion (e.g., SIP-to-SS7 and 
vice versa via the MGCF 42 and T-SGW 43 interface) and (2) control of transcoding 

30 (e.g., speech data in RTP payload formats-to-PCM transcoding and vice versa in the 
MGW 34). 
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The wireless core network 1 1 is capable of providing conventional packet data 
services, such as electronic mail, web browsing, file transfer, and so forth, for the mobile 
stations 1 6, 1 8, 20 and 22. Such data services may be provided for communications 
sessions between a mobile station and an endpoint coupled to the packet data network 28 

5 or PSTN 36. The wireless core network 1 1 is also capable of providing packet-switched 
voice and other real-time communications between the mobile stations 16, 18, 20 and 22 
and endpoints coupled to the packet data network 28 or PSTN 36. As used here, "real- 
time communications" refers to communications in which data is exchanged on a 
substantially real-time basis between two endpoints (that is, the communication is delay 

1 0 intolerant). Examples of real-time data include voice data exchanged in a call (or 

telephony) session, video data exchanged in a video conferencing session, and so forth. 

In packet-switched communications, user data such as voice or other types of data 
are carried in packets, such as IP packets. In one embodiment, real-time data such as 
voice is converted to a Real-Time Protocol (RTP) format and carried as an RTP payload 

15 in a UDP packet that is encapsulated in an ff packet. RTP is described in RFC 1889, 
entitled "RTP: A Transport Protocol for Real-Time Apphcations," dated January 1996. 
RTP defines end-to-end transport functions that are suitable for real-time data, such as 
audio, video, or other data. 

IP provides network layer functionality (node-to-node routing functionality) for 

20 packet-switched communications over a network. Unlike circuit-switched networks, 
which provide a dedicated (connection-oriented paradigm) end-to-end channel portion 
(e.g., a time slot) for the duration of the call session, a packet-switched network that uses 
UDP as the transport layer and IP as the network layer is based on a connectionless 
oriented paradigm (both end-to-end and node-to-node). Packets or other units of data 

25 injected into a packet-switched data network may travel independently over any path (and 
possibly over different paths) to a destination point. For best effort quality of service, 
routing of packets in packet-switched communications is based on destination addresses 
carried in IP packets. 

The overhead portion of each packet that carries real-time data can be rather large 

30 due to the presence of several headers, including RTP and IP headers as well as a User 
Datagram Protocol (UDP) header. UDP is described in RFC 768, entitled "User 
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Datagram Protocol/' dated August 1980. One issue associated with carrying the protocol 
header information, which in one embodiment includes the RTP, UDP, and IP headers, is 
the increased bandwidth required to carry the overhead information. This reduces 
spectral efficiency over the air interface (where bandwidth is a scarce and expensive 

5 commodity) between mobile stations and respective radio network controllers 12 and 14, 
In addition, channel coding and interleaving schemes that have been standardized for 
channels carrying circuit-switched voice traffic (without the protocol headers) may no 
longer be acceptable for packet-switched voice traffic encapsulated in packets containing 
the RTP, UDP, and IP header information. Consequently, new channel coding and 

1 0 interleaving standards may have to be developed and adopted, which is typically a time 

consuming and complex process. Also, radio equipment (such as base stations) may have 
to be replaced if new channel coding and interleaving schemes are developed. 

To address these issues, each end of the air interface between a mobile station and 
a radio network controller is capable of removing the RTP, UDP and IP headers from 

1 5 each packet before transmission of bearer traffic (e.g., voice data or other form of real- 
time data) over the air interface. Alternatively, instead of removing the protocol headers, 
a mobile station can simply choose not to generate the protocol headers. The receiving 
end then reconstructs the RTP, UDP, and IP header information. Thus, what is sent over 
the air interface is the bearer traffic itself without the overhead of the RTP, UDP, and IP 

20 headers. A benefit of sending bearer traffic (e.g., voice-over-IP data) without protocol 
headers is that existing channel coding and interleaving schemes can be used. Also, 
spectral efficiency is enhanced since communication of overhead information in each and 
every bearer packet can be avoided. 

At least two alternative implementations of the protocol header 

25 removal/reconstruction scheme are possible. In a first implementation, the mobile station 
is a device (or plural devices) that requires the RTP/UDP/IP header information to be (1) 
constructed and then removed for voice data (or other forms of real-time data) 
transmitted on the uplink path from the mobile station to the radio network controller, 
and (2) reconstructed for voice data (or other forms of real-time data) received on the 

30 downlink path from the radio network controller to mobile station. In one example, the 
mobile station includes a computer (referred to as the TE device) coupled to a terminal 
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(referred to as the MT device) capable of wireless communications with base station 
transceiver and a radio network controller. The combination of the TE and MT devices 
makes up the mobile station or user equipment (UE). In this example, the computer (or 
TE device) expects to receive voice packets (or other forms of real-time packets) that 

5 contain the appropriate protocol headers (e.g., RTP/UDP/IP headers) for the packet- 
switched communications. 

hi another arrangement of the first implementation, the mobile station is a single 
integrated device that includes software layers, including a protocol stack (e.g., 
RTPAJDP/IP stack), to receive packets that contain RTP/UDP/EP headers. 

10 hi the first implementation, the mobile station removes RTP/UDP/IP header 

information from packets that are communicated on the uplink to the radio network 
controller. The mobile station reconstructs RTP/UDP/IP header to add to packets 
containing bearer data received on the downlink. 

In a second implementation, the mobile station can be a device such as a 

1 5 telephone that does not need to generate or reconstruct RTP/UDP/IP header information 
for voice data (or other forms of real-time data) transmitted on the uplink or received on 
the downlink, respectively, hi this example, the mobile station mcludes the MT device 
without the TE device. Thus, bearer traffic, such as voice-over-IP data or other forms of 
real-time data, are passed directly to the other components of the mobile station for 

20 processing without reconstructing protocol headers. On the uplink, the mobile station 

either removes RTP/UDP/IP header information from packets or never actually generates 
the RTP/UDP/IP header information so that bearer data is communicated on the uplink 
without protocol headers. 

In both implementations, the radio network controller (12 or 14) removes protocol 

25 headers associated with a packet-switched communications session before transmitting 
bearer traffic on the downUnk. For example, IP packets containing bearer traffic are 
received from the SGSN 24. The radio network controller 12 or 14 removes the 
RTP/UDP/IP headers from the packets and communicates the bearer traffic without the 
protocol headers over the downlink of the air interface to the target mobile station. 
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On the uplink, the radio network controller receives bearer traffic without 
protocol headers. It then reconstructs the protocol headers to add to packets containing 
the bearer traffic for communication to the SGSN 24, 

Referring to Fig. 2, an IP packet 200 for carrying bearer traffic (e.g., voice traffic 

5 or other forms of real-time traffic) is illustrated. The packet 200 includes an IP header 
202, a UDP header 204, an RTP header 206, and a payload section 208. In the illustrated 
example, the payload section 208 carries the bearer traffic in RTP format. 

In a packet-switched communications session over an IP network that involves an 
exchange of real-time data (e.g., voice data), IP packets according to the format of packet 

1 0 200 are communicated between endpoints. At the transmitting endpoint, real-time data is 
converted into RTP format, and added as payload to the UDP/IP packet. The IP packet is 
communicated over the IP network to the receiving endpoint, where the real-time data is 
extracted. The IP header contains source and destination addresses that are used for 
routing the respective RTP/UDP/IP packet; however, to provide a quality of service that 

1 5 is better than best effort, other parameters such as UDP source and destination ports and 
protocol type number may also be additionally used for routing. The UDP header 
identifies UDP source and destination ports, and the RTP header identifies characteristics 
of the real-time data in the payload. In the context of Fig. 1, the mobile station is one 
endpoint that is capable of participating in a packet-switched commvmications session 

20 with another endpoint (e.g., one of devices 30, 32 coupled to the packet data network 28, 
the media gateway 34, or another mobile station). 

To enable construction of the protocol header information, the IP, UDP, and RTP 
header information is communicated in configuration messages exchanged over the air 
interface between a mobile station and a radio network controller as part of the call setup 

25 procedure. The RTP, UDP, and IP information carried in the configuration messages is 
stored by the mobile station and/or radio network controller. The stored information 
enables the mobile station and/or radio network controller to construct the RTP, UDP, 
and IP header information in response to the mobile station and/or radio network 
controller receiving bearer traffic (e.g., voice data or other form of real-time traffic). 

30 Thus, for example, in the uplink direction, the mobile station removes (or does not 
generate) the RTP, UDP, and IP headers and sends only bearer traffic over the air 
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interface to the radio network controller. Upon receiving the bearer traffic from the 
mobile station, the radio network controller accesses the stored configuration information 
to construct the IP, UDP, and RTP headers, with which IP packets carrying RTP payload 
can be constructed. Similarly, on the downlink, the radio network controller removes the 

5 RTP, UDP, and IP headers and transmits only bearer traffic over the air interface to the 
mobile station. According to one embodiment, the mobile station accesses stored 
configuration information to reconstruct the RTP, UDP, and P header information for 
recreating IP packets. In another embodiment, the mobile station does not need to 
reconstruct the RTP, UDP, and IP header information. 

1 0 In one example, the configuration messages exchanged between the mobile 

stations and radio network controllers include the following: UPLINK PROTOCOL 
HEADER CONFIGURATION message, UPLINK PROTOCOL HEADER 
CONFIGURATION COMPLETE message, DOWNLINK PROTOCOL HEADER 
CONFIGURATION message, DOWNLINK PROTOCOL HEADER 

1 5 CONFIGURATION COMPLETE message, DOWNLINK PROTOCOL HEADER 
RECONFIGURATION message, and DOWNLINK PROTOCOL HEADER 
RECONFIGURATION COMPLETE message. 

The UPLINK PROTOCOL HEADER CONFIGURATION message is sent by a 
mobile station to a radio network controller and contains various predetermined RTP, 

20 UDP, and IP header information that are to be part of the RTP/UDP/IP headers in packets 
communicated in packet-switched communications. The information in the UPLINK 
PROTOCOL HEADER CONFIGURATION message is used by the radio network 
conti-oUer to reconstiaict the RTP/UDP/IP headers to add to packets originated by the 
mobile station. The UPLINK PROTOCOL HEADER COl^JFIGURATION message 

25 contains the following information elements: 



INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




KB Identity 


MP 


RTP/UDP/IP HEADER INFORMATION ELEMENTS 




CP Version 


MP 


Source IP Address 


MP 
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ripctinjitiriTi TP AHHrp^^ 


MP 


niff^erv Cade Point rDSCP"! 


OP 


^nnrrp TTDP Port 


MP 


Df^Qtinatiorj TTDP Port 


MP 


RTP Versiori 


OP 


RTP Pavload Type (PT) 


MP 


RTP Synchronization Source Identifier (SSRC) 


MP 


RTP Sequence Number 


MP 


RTP Timestamp 


MP 


RTP Clock Frequency 


OP 



The first column identifies the information elements and the second column 
identifies whether each information element is mandatory (MP) or optional (OP). A 
Message Type information element identifies the type of message, which in this case is 
5 the UPLINK PROTOCOL HEADER CONFIGURATION MESSAGE. An RB Identity 
information element identifies the radio bearer. 

The remaining information elements of the UPLINK PROTOCOL HEADER 
CONFIGURATION message are information elements carrying RTP, UDP, and IP 
header information. An IP Version information element indicates the format of the IP 
10 header (e.g., IPv4 or IPv6). A Source IP Address information element contains the IP 

address of the source endpoint, in this case the mobile station. A Destination IP Address 
information element identifies the IP address of the destination endpoint, which can be 
the media gateway 34, an endpoint coupled to the packet data network 28, or another 
mobile station. 

1 5 A Diff-Serv Code Point (DSCP) information element identifies the DSCP value. 

According to the differentiated services (Diff-Serv) quality of service (QoS) framework, 
the DSCP selects the per-hop behavior that a packet experiences at each node (e.g., a 
router) along a network path. The value of DSCP that is contained in each IP packet 
specifies a desired level of services. The Diff-Serv model employs a reservation-less 

20 mechanism for providing differentiated classes of services for network traffic. Diff-Serv 
is described in RFC 2474, entitled "Definition of the Differentiated Services Field (DS 
Field) in the IPv4 and IPv6 Headers," dated December 1998; and RFC 2475 entitled "An 
Architecture for Differentiated Services," dated December 1998. 
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A source UDP Port information element specifies the UDP port of the source 
endpoint (the mobile station). A Destination UDP Port information element specifies the 
UDP port of the destination endpoint. 

Several RTP information elements are also carried in the UPLINK PROTOCOL 

5 HEADER CONFIGURATION message. An RTP Version information element contains 
the version (V) field that identifies the version of RTP. An RTP Payload Type (PT) 
information element contains the payload type (PT) field of the RTP header, which 
identifies the format of the RTP payload and determines its interpretation by a software 
application. An RTP Synchronization Source Identifier (SSRC) information element 

1 0 contains the SSRC field of the RTP header. The SSRC field identifies the 

synchronization source of a stream of packets. All packets from a synchronization source 
form part of the same timing and sequence number space, so a receiver groups packets by 
synchronization source for playback. 

An RTP Sequence Number information element contains the sequence number of 

1 5 the RTP header. The sequence number for each RTP packet sent in a communications 
session increments according to calculations based upon (1) the RTP Clock Frequency 
information element (e.g., 8,000 Hz for the AMR-NB speech codec or 16,000 Hz for the 
AMR-WB speech codec) and (2) the speech codec frame duration (e.g., 20 milliseconds 
for both the AMR-NB and AMR-WB speech codecs). The sequence number is used to 

20 detect packet loss and to restore packet sequence. 

An RTP Timestamp information element contains the timestamp field of the RTP 
header. The timestamp field reflects the sampling instant of the first octet or byte in the 
RTP data packet. The sampling instant is derived from a clock that increments 
monotonically and linearly in time to allow synchronization and jitter calculations. In the 

25 UPLINK PROTOCOL HEADER CONFIGURATION message, the frequency of the 
clock is specified in an RTP Clock Frequency information element. 

The UPLINK PROTOCOL HEADER CONFIGURATION COMPLETE message 
is sent by the radio network controller to the mobile station to confirm the exchange of 
the header information (in response to receipt of the UPLINK PROTOCOL HEADER 

30 CONFIGURATION message). The message is shown below: 
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INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 



The UPLINK HEADER CONFIGURATION COMPLETE message contains a 
Message Type information element to indicate the type of message (in this case UPLINK 
PROTOCOL HEADER CONFIGURATION COMPLETE), and an RB Identity 
5 information element to identify the radio bearer. 

hi one embodiment, the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message is sent by the radio network controller to the mobile station 
to enable the mobile station to reconstruct the RTP, UDP, and IP header information. 
Note that the DOWNLINK PROTOCOL HEADER CONFIGURATION message is sent 
1 0 to mobile stations that are configured to reconstruct RTP/UDP/IP headers. For mobile 
stations that are not configured to reconstruct RTP/UDP/IP headers, communication of 
the DOWNLINK PROTOCOL HEADER CONFIGURATION message is not 
performed. 

The DOWNLINK PROTOCOL HEADER CONFIGURATION contains the 
15 following: 



INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 


RTP/UDP/IP HEADER INFORMATION ELEMENTS 




DiffServ Code Point (DSCP) 


OP 


RTP CSRC Count (CC) 


OP 


RTP Synchronization Source Identifier (SSRC) 


MP 


RTP Contributing Source Identifier (CSRC) 


OP 


RTP Sequence Number 


MP 


RTP Timestamp 


MP 



The DOWNLINK PROTOCOL HEADER CONFIGURATION information 
element contains a Message Type information element and an RB Identity information 
20 element. In addition, the message contains various RTP-related information elements 
and a QoS-related information element. Note that the DOWNLINK PROTOCOL 
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HEADER CONFIGURATION message does not include IP and UDP source and 
destination address and port information. Since the mobile station is UDP and IP-aware, 
the mobile station is able to determine the IP address and UDP port information from call 
control signaling used to establish a packet-switched communications session (e.g., SIP 
5 signaling). 

A Diff-Serv Code Point (DSCP) information element (which contains QoS related 
information) contains the DSCP code for specifying a level of service for packets 
communicated in the communications session. An optional RTP CSRC Count (CC) 
information element contains the CSRC count value in an RTP header. The CSRC Count 

1 0 value contains the number of CSRC identifiers that are in a CSRC hst (described below). 
The message also contains an RTP Synchronization Source Identifier (SSRC) 
information element as well as an RTP Contributing Source Identifier (CSRC) 
information element. The RTP CSRC information element contains a CSRC hst 
(contained in an RTP header) that identifies the contributmg sources for a payload 

1 5 contained in the packet. The number of CSRC identifiers in the CSRC list is specified in 
the RTP CSRC Count (CC) information element. Thus, in a multi-party call, the CRSC 
list identifies all parties that are involved in the call. In a multi-party call, such as a 
conference call, voice data from multiple persons may be mixed together. The CSRC list 
enables the identification of possible sources of the combined voice data. The CSRC 

20 identifiers are typically inserted by RTP mixers. 

Other information elements in the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message include an RTP Sequence Number information element 
and an RTP Timestamp information element. 

A DOWNLINK PROTOCOL HEADER CONFIGURATION COMPLETE 

25 message is communicated in response to DOWNLINK PROTOCOL HEADER 
CONFIGURATION message, and contains the following elements. 



INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 
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Once a packet-switched call has been estabUshed and is ongoing, the possibility 
exists for either of the two parties to conference in additional parties. The multi-party 
call setup is done using SIP signaling (or other call control signaling). Once additional 
parties have been conferenced in, the downlink RTP packets from the multi-parties 
5 typically go through an RTP mixer, where the voice data from multiple sources are mixed 
into a single RTP packet. In a two-party call, the downlink RTP packet header includes 
the standard 12 bytes according to RFC 1889. 

However, once additional parties have been conferenced in, the downlink RTP 
packet header increases in size since additional RTP fields are included in the RTP 
1 0 header. One field that is mcluded is the CSRC count field (CC). If the value of CC is 
zero, then the call is a two-party call. If the value of CC is one, then the call is a three- 
party call. Given CC = N, there will be N CSRC identifiers in the RTP packet header. 
The list of CSRC identifiers is present only when inserted by an RTP mixer. The 
presence of this list is indicated by the parameter CC. Thus, the radio network controller 
15 can continuously snoop or monitor the parameter CC in messages received from the 

SGSN 24 to determine if the RTP/UDP/IP information in the mobile station needs to be 
reconfigured due to the presence of additional parties in the call. 

The reconfiguration is performed by use of a DOWNLINK PROTOCOL 
HEADER RECONFIGURATION message, whose content is provided below: 

20 



INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 


RTP/UDP/IP HEADER INFORMATION ELEMENTS 




DiffServ Code Point (DSCP) 


OP 


RTP CSRC Count (CC) 


OP 


RTP Synchronization Source Identifier (SSRC) 


MP 


RTP Contributing Source Identifier 


OP 


RTP Sequence Number 


MP 


RTP Timestamp 


MP 



To acknowledge the DOWNLINK PROTOCOL HEADER 
RECONFIGURATION message, the mobile station sends a DOWNLINK PROTOCOL 
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HEADER RECONFIGURATION COMPLETE message. The content of this message is 
provided below: 



INFORMATION ELEMENT/GROUP NAME 


NEED 


Message Type 


MP 


RB INFORMATION ELEMENTS 




RB Identity 


MP 



5 Referring to Fig. 3, a call setup procedure according to one embodiment is 

illustrated. In this embodiment, packet-switched call setup is performed using SIP 
messaging. The entities involved in the call setup include a mobile station (labeled UE), 
a radio network controller, the SGSN 24, the GGSN 26, the CSCF 40, the MGCF 42, and 
the media gateway 34. It is assumed that the mobile station UE is the initiator of the call, 

1 0 with the target being a terminal coupled to the PSTN 36, such as telephone 3 8 in Fig. 1 . 
For purposes of the packet-switched call, the terminating endpoint is the T-SGW 43 (Fig. 
1) for control signaling and the media gateway 34 for bearer traffic. Packet control 
signaling and bearer traffic is converted to traditional circuit-switched control signaling 
and traffic for communication over the PSTN 36. 

1 5 The mobile station first performs a radio resource control (RRC) connection setup 

(at 100) with the radio network controller. Next, the mobile station performs a GPRS 
attach procedure (at 102). The GPRS attach procedure is performed to inform the radio 
access network that the mobile station is available. Next, to activate a primary PDP 
(Packet Data Protocol) context, the mobile station sends (at 104) an Activate PDP 

20 Context request, which is processed by the SGSN 24 and the GGSN 26. The primary 
PDP context includes, among other things, the default QoS profile for the requested 
connection. As part of the primary PDP Context activation procedure, the SGSN 24 
performs a radio access bearer assignment procedure to assign one or more radio access 
bearers to the mobile station. 

25 After the primary PDP context has been activated, a SIP registration procedure is 

performed (at 106). The SIP registration procedure is performed with the CSCF 40, 
which includes the SIP proxy. SIP registration is performed to set up the profile for the 
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mobile station in the CSCF 40, so that the CSCF 40 is aware of the mobile station's 
existence as well as various configuration information associated with the mobile station. 

After Sn* registiration, the mobile station can initiate a packet-switched call by 
sendmg call setup messages (at 108). To initiate a call, the SP INVITE request is sent, 
which includes the destination address of the terminal being called and indicates that the 
called terminal is being invited to participate in a call session. Various acknowledgment 
messages, as defined by Sff , are also exchanged between the mobile station and the 
CSCF 40. The SIP messages are routed through the CSCF 40 since tiie CSCF 40 acts as 
the SIP proxy. 

Next, the mobile station mitiates an activates secondary PDP context procedure 
(at 110). A different QoS profile can be assigned in the secondary PDP context to enable 
a higher level of service if desired for the bearer traffic (e.g., packet-switched speech 
data). After the activate secondary PDP context procedure, fiirther SIP call setup 
messages are exchanged (at 1 12) between the mobile station and the CSCF 40. After all 
appropriate SIP messages have been exchanged, an RTP bearer path is estabUshed (at 
114). In the RTP bearer path, IP packets containing RTP payloads are exchanged. 

However, in accordance with some embodiments of the invention, the 
RTP/UDP/IP header information is stripped before being communicated over the air 
mterface between the mobile station and the radio network controller. Thus, for example, 
if the media gateway 34 sends a packet containing RTP bearer data (at 116), the entire IP 
packet is not actiially communicated across the air interface. As described above, the 
RTP/UP/IP headers are removed before being communicated. 

Before that can occur, the radio network controller sends a DOWNLINK 
PROTOCOL HEADER CONFIGURATION message (at 1 18) to the mobile station, 
according to one implementation. Note that the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message may not be needed if the mobile station does not need to 
reconstiTict RTP/UDP/ff headers. The mobile station stores the configuration 
information (at 120) carried by the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message. The mobile station then acknowledges the message by 
returning (at 122) a DOWNLINK PROTOCOL HEADER CONFIGURATION 
COMPLETE message to the radio network contiroUer. Upon receiving the DOWNLINK 
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PROTOCOL HEADER CONFIGURATION COMPLETE message, the radio network 
controller sends the bearer data (received from the media gateway 34) over the air 
interface (at 124) to the mobile station. The bearer data is sent without the RTPAJDP/IP 
headers, which have been removed by the radio network controller. 

5 Similarly, if the mobile station desires to transmit bearer data targeted for the 

media gateway 34, it sends the bearer data without the RTP/UDP/IP header information. 
Before doing so, the mobile station sends (at 126) an UPLINK PROTOCOL HEADER 
CONFIGURATION message to the radio network controller. The radio network 
controller then stores (at 128) the configuration information carried by the UPLINK 

1 0 PROTOCOL HEADER CONFIGURATION message. In response, the radio network 
controller retums (at 130) an UPLINK PROTOCOL HEADER CONFIGURATION 
COMPLETE message to the mobile station. At this point, the mobile station is able to 
remove RTP/UDP/IP header information so that only bearer data is commxmicated across 
the air interface to the radio network controller. Upon receipt of the bearer data, the radio 

1 5 network controller is able to reconstruct the RTP/UDP/IP headers, which are added to 

packets and communicated to the media gateway 34 through the SGSN 24 and GGSN 26. 

Referring to Fig. 4, an entity on the air interface (e.g., a mobile station that is able 
to reconstruct RTP/UDP/IP headers or a radio network controller) determines (at 304) if 
the entity has received inbound bearer traffic. If so, the entity reconstructs the 

20 RTP/UDP/IP headers (at 304). The RTP/UDP/IP headers are then added to IP packets 
that contain the bearer traffic (at 306). The IP packets are communicated (at 308) to the 
target (which may be a node or terminal coupled to a network, such as the SGSN 24, or 
some software application or other element within the entity). 

Referring to Fig. 5, the procedure for transmitting bearer data is illustrated. If the 

25 entity (either the mobile station or radio network controller) detects receipt of outbound 
bearer traffic (at 402), which may be fi-om a node or terminal coupled to a network or 
from an intemal resource, the entity removes (or does not generate) RTP/UDP/IP headers 
for the bearer data. The bearer data is then transmitted (at 406) without the RTP/UDP/IP 
headers over the air interface. 

30 Referring to Fig. 6, various components of the mobile station (referred to as 500) 

and radio network controller (referred to as 502) are illustrated. The mobile station 500 
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includes a lower physical layer 504, referred to as a radio frequency (RF) layer. The RF 
layer 504 is responsible for the RF signaling protocol between the mobile station and the 
radio network controller over an air interface or wireless link 506. Above the RF layer 
504 is a medium access control (MAC) layer 508. The MAC layer 508 controls the 
5 access signaling (request and grant) procedures for the radio channel. Above the MAC 
layer 508 is a radio link control (RLC) layer 510. The RLC layer 510 provides a radio- 
solution-dependent reliable link. 

Further layers are defined above the RLC layer 510. hi the illustrated example, 
such layers are referred to as a mapping protocol layer(s) 512, which are typically part of 

10 the Packet Data Convergence Protocol (PDCP) layer in UMTS. The PDCP layer is 

responsible for header compression/decompression. For example, according to GPRS the 
mapping protocol layer 512 includes an SNDCP (subnetwork dependent conversion 
protocol) layer. The SNDCP layer maps network-level characteristics onto the 
characteristics of the underlying network and is responsible for header compression and 

1 5 decompression. Further layers may also be present, although not shown. 

On the other hand, according to UMTS, the mapping protocol layer 512 includes 
a packet data conversion protocol (PDCP) layer. The PDCP layer maps high-level 
characteristics onto the characteristics of the underlying radio-interface protocols and is 
responsible for header compression and decompression. PDCP provides protocol 

20 transparency for higher-level protocols. PDCP supports IPv4, IPv6, and PPP. 

Above the mapping protocol layer 512 is a UDP/IP stack 514. The mobile station 
500 also includes a SEP stack 516 for processing SIP control signaling. The SIP 516 
interacts with one or more software applications 518. For example, the appUcations 518 
may include user interface applications that allow a user to make phone calls. For bearer 

25 traffic, data is routed through an RTP layer 520. For outbound traffic, the RTP layer 520 
converts the bearer data into RTP format. For inbound traffic, the RTP layer 520 extracts 
RTP payload. 

The RTP bearer data is passed through a coder/decoder (CODEC) 524. The 
CODEC 524 communicates through an analog-to-digital converter 526 to convert 
30 outbound data into analog format and to convert inbound analog data into digital format. 



20 



The AID converter 526 communicates with an I/O device 528, such as a speaker and 
microphone. 

The mobile 500 also includes a header control module 522, which is responsible 
for constructing RTP/UDP/IP information for inbound traffic (according to one 
5 arrangement). The header control module 522 is also responsible for causing the removal 
of RTP/UDP/IP header information (or alternatively, making sure that the RTP/UDP/IP 
information is not generated) for outbound traffic. 

The various layers and modules in the mobile 500 can be implemented as 
software, hardware, or a combination of both. Software is executable on a control unit 

10 530, which is coupled to a storage unit 532. The storage unit 532 stores various data, 

such as header configuration information 534, and instructions of software. The header 
configuration information 534 is derived fi-om the DOWNLINK PROTOCOL HEADER 
CONFIGURATION message or DOWNLINK PROTOCOL HEADER 
RECONFIGURATION message that is received fi-om the radio network controller 502, 

1 5 The radio network controller 502 includes an RF layer 540, an MAC layer 542, 

and an RLC layer 544. The radio network controller 502 also includes a relay fimction 
546 that forwards data received fi:om one node to the next node in the route. In the radio 
network controller 502, the relay fimction 546 forwards data between the interface to the 
wireless link 506 and the interface to the SGSN 24, which is made up of a physical layer 

20 552 (or LI layer) and upper layers 550. 

The radio network controller 502 also includes a header control module 548 that 
is responsible for removing and reconstructing RTP/UDP/IP headers. The various layers 
in the radio network controller 502 can be implemented in software, hardware, or a 
combination thereof. Software is executable on a control unit 554, which is coupled to a 

25 storage unit 556, The storage unit stores various data (including header configuration 

information 558) and instructions of software. The header configuration information 558 
is derived from UPLINK PROTOCOL HEADER CONFIGURATION messages. Note 
that the radio network controller 502 can store header configuration information 558 of 
multiple mobile stations. 

30 The various devices and systems discussed each includes various soflware 

routines or modules. Such software routines or modules are executable on corresponding 
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control units. Each control unit includes a microprocessor, a microcontroller, a processor 
card (including one or more microprocessors or microcontrollers), or other control or 
computing devices. As used here, a "controller" refers to a hardware component, 
software component, or a combination of the two. Although used in the singular sense, a 
5 "controller" can also refer to plural hardware components, plural software components, 
or a combination thereof 

The storage units referred to in this discussion include one or more machine- 
readable storage media for storing data and instructions. The storage media include 
different forms of memory including semiconductor memory devices such as dynamic or 

10 static random access memories (DRAMs or SRAMs), erasable and programmable read- 
only memories (EPROMs), electrically erasable and programmable read-only memories 
(EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable 
disks; other magnetic media including tape; and optical media such as compact disks 
(CDs) or digital video disks (DVDs). Instructions that make up the various software 

1 5 routines or modules in the various devices or systems are stored in respective storage 
units. The instructions when executed by a respective control unit cause the 
corresponding device or system to perform programmed acts. 

The instructions of the software routines or modules are loaded or transported to 
each device or system in one of many different ways. For example, code segments 

20 including instructions stored on floppy disks, CD or DVD media, a hard disk, or 

transported through a network interface card, modem, or other interface device are loaded 
into the device or system and executed as corresponding software routines or modules. 
In the loading or transport process, data signals that are embodied in carrier waves 
(transmitted over telephone Unes, network lines, wireless links, cables, and the like) 

25 communicate the code segments, including instructions, to the device or system. Such 
carrier waves are in the form of electrical, optical, acoustical, electromagnetic, or other 
types of signals. 

While the invention has been disclosed with respect to a limited number of 
embodiments, those skilled in the art will appreciate numerous modifications and 
30 variations therefrom. It is intended that the appended claims cover such modifications 
and variations as fall within the true spirit and scope of the invention. 



